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* What is Human System Integration? 


Human Systems Integration: 


An interdisciplinary and comprehensive management and technical process that 
focuses on the integration of human considerations into the system acquisition and 
development processes to enhance human system design, reduce life-cycle 
ownership cost, and optimize total system performance (NPR 7123.1B). 


HSI integrates the Human Element: 


«A process by which human capabilities and limitations are effectively and 
NPR 7123.1B defines the system 4s affordably integrated equally during systems design and development 


hardware + software + humans vy 


...but says very little on how to integrate 


humans and systems. , 4 
QISIY software Hardware 


The Promise of HSI 


e System Optimization due to: 

e Reduced manpower numbers 

e Simplified requirement for personnel skills eHiderey 
e Reduced training needs 
e Simplified maintenance and logistics 


e Mishap avoidance 


e Avoidance of system rework costs 


e Designs that are focused on the needs of operators, maintainers, and other 
support personnel 


e Demonstrates “return on investment” of HSI in human spaceflight through 
engagement of all domains and organizations 


e Stakeholders and domains are engaged early and often in the lifecycle 
e Promotes total system performance (increased effectiveness and efficiency) 
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A Why early? Reduce Risk & Optimize Performance 


Training Issues Planning Issues 
Lack of Familiarity No Hand-off 
First Time Syndrome Insufficient Time Slot 
Big Picture Missing PI not present during Ops 
Excessive 
Crew 
- a Time 
Difficult operating in micro-G Poorly Written Procedures 
Small items must be secured Unclear Procedures / Steps 
Needed help to operate Missing Steps in Procedure 
HW/SW Usability Issues Process Issues 


Ref: Categorical example; Grouping of the 109 payload-related crew notes per Dr. Beard/NASA-Ames 


nasa Why HSI? A DoD HSI Success Story 
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Comanche Tool Kit 


e The tool box for the T-53 series helicopter turbine engine (Huey & Iroquois) had 134 
different tools. 
e Because of the Department of Defense tool MANPRINT (Manpower & Personnel 


Integration), and its inclusion of HSI in the design process, the tool KIT for the T-800 for 
the Comanche has six tools instead of 134. 


e And the tools are inexpensive & commercially spr ng Miranda 
Without MANPRINT 
e Result: hp Different Tools 
lt T T 
e Fewer tools Bini BNA leopife\TT aN Tish i 


IT Tal i& Lye Ty a 
e Less burden on the supply system TTL LL DTA p27 Tay Sah 


e Less training and inventory time 
e Increased combat readiness 


By) PS BNL J! SABA TIN TUS 


With MANPRINT 6 Toois 


Which would You Prefer? 
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ASA How do we know HSI matters? Cost. 


¢ Lifecycle cost reduction is the E 100% Sonwnited Costs — 95% 
goal that drives HSI 2 90% | — 85% 
e Based upon analyses by the DoD 2 sow a 500-1000X 
and by INCOSE (International Does ; ge? 
Council on Systems Engineering) Soo om a opester 
80% of new systems’ costs occur CO oe Prod/Test rae 
after development = 60% 7 
® 3-6X 
e These major operations phase s “ 
costs are human-related: : 30% Devsiep 
e Manpower, Personnel, ° “ Design 50% 
Training S 10% 20% tenes 
e Rework of human interfaces 5 aid Time 


e Logistics and maintenance 


a k iff , HSI t engage at program/project outset 
© Poor human /system o make a difference, HSI must engag prog proj U 


performance * Once operational, it is extremely expensive--typically prohibitively-- 
to rework systems for human/system efficiency and effectiveness 


NASA Example: The Shuttle Concept vs. Reality 


Concept 

e “Jet aircraft” style hanger 

¢ 5 weeks turnaround time 

¢ 40 flights per year for 
fleet of 3 vehicles 


Reality 


ee / |) eae eae a ; 
= 8 —~ Classic Problems 


¢ Insufficient definition of 
Ops requirements 


¢ Focus on Performance 


¢ Developers not 
responsible for 
Operational Costs 


¢ Very few incentives for 
addressing turn-around 


Elaborate scaffolding time or maintainability 


Large number of service 
workers required 
~4 flights per year, average 


Source: Bo Bejmuk, Space Shuttle Integration (Lessons Learned Presentation) 
See HSIPG Appendix C section 2 for more details 
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A Elements of HSI at NASA 


Human Systems Integration encompasses all these areas at NASA 


Habitability and Human ».@ Human Health & Performance & Mission Operations 


Factors Branch (SF3) 


Human-Centered Standard 
Human Factors 
Environmental Factors 


° Operations Experience 
e 

e 

e Habitability 

e 

e 

e 


Maintenance & Logistics 
Training 
Personnel & Manpower 


Training 


Flight Medicine Budgeting 
e Full-cost Accounting 


a Astronaut Office e Life Cycle Cost Estimates 
e Astronaut Support 
e Flight Crews Summaries Legal & Contracts 


e Anecdotal Evidence e Acquisition Strategy 
Engineering Ground Operations 
e Design Safety & Mission ° |osistics 
: : ~ Personnel & Manpower 
e Systems Engineering Assurance 
e Program Management Safety 
e Training 


Human-Rating 

Human Reliability 

Survival Analyses 
Maintainability 
Supportability 

Probabilistic Risk Assessment 


(NaS , @ What is Human Factors? 


Human Factors in design: 


e Design for the human/system interface and 
account for both cognitive and physical limits. 


Key Measures/Goals 

e Improve effectiveness 

e Improve efficiency 

e Improve safety 

e Improve situational awareness 
e Reduce errors 

e Reduce workload 

e Reduce fatigue 

e Reduce the training demand 

e Ensure operability and usability 
e Improve satisfaction 

e Meet user’s needs and wants 

e Improve user’s perception of product 


Early involvement is key: “You can use an eraser on the drafting table ora 
sledgehammer on the construction site.” — Frank Lloyd Wright 


NASA How do we do Human Factors? 


Human Factors is composed of a number of 

unique disciplines including: 

¢ Cognitive Psychology 

¢ Industrial Psychology 

¢ Biomechanics 

¢ Human/Computer Interaction 

¢ Industrial Design 

e Architecture 

¢ Other Engineering and Science specialty 

domains 

Human Factors practitioners develop, apply, 

and verify according to: 

¢ Spaceflight Human Systems Standard 
(NASA-STD-3001 Volume 2) 

¢ Human Integration Design Handbook 
(SP-2010-3407) 

¢ Human Systems Integration Practitioner’s Guide 
(SP-—2015-3709) 

¢ NASA Institutional Review Board processes 

¢ Program-specific requirements and processes 


User, Task, & 
=~ .. Environment 


Solutions 


| Designs 


i » 


Human Factors processes ensure that the design 
meets the users’ intent and capabilities / limitations 


NASA Why Human Factors? 


e These humorous examples make the point of why Human Factors is needed. 


© Some say that Human Factors is “common sense”. While there is a degree 


of truth to that, not all Human Factors design challenges are as obvious as 
below. 


e When designing for microgravity operations, consider the ways in 
which the lack of gravity can both help and hurt the ability of crew to Two-handed 
perform tasks. glovebox operation 


e Some tasks like moving large objects is considerably easier in with foot restraint 


microgravity. Objects have mass, but they don’t have weight, which 
means maneuvering them can be easier. However, stopping objects 
from moving can be challenging. 


e Some tasks are harder in microgravity. Because of lack of gravity, crew 
does not have the same leverage when manipulating objects, such as 
torqueing a connector or fastener. 


That’s the rationale behind the one-handed operation guideline, because 
while the crew is manipulating the object with their dominant hand, their 
other hand is used to stabilize themselves to provide leverage. 


Certain major operations, like glovebox tasks, can require two hands, in 
which case the crew will decide to restrain their feet, using a handle rail, 
or foot restraint. Two-handed operations should be limited to operations 
where there is no other choice. 13 


NASA Designing hardware for microgravity environment 


e Cautionary Note: There can be unanticipated consequences of microgravity’s effect on hardware. For 
example, International Subrack Interface Standard (ISIS) locker handles have a spring effect that is more 
severe in space than in 1G. They have pinched multiple crew members’ fingers causing pain or minor 
injury. 

e This effect was not discovered during ground testing. 
e The lesson is when designing mechanical devices where stored energy is part of their function, take 
steps to eliminate pinch hazards. 


14 


e Lack of gravity means objects float away easily 
and do not stay nicely arranged, such as when 
we arrange objects on a table in 1G. Maintenance Work Area: 


e The captive parts requirement is meant to Example of maximum Velcro per area 
prevent objects from floating away and causing 
crew injury, or getting stuck in filters, fans, or 
other mechanisms causing hardware damage. 


e Bags of science samples, tools, etc. should have 
Velcro on the back to allow the crew to 
temporarily stow them nearby on a rack or work 
area, keeping them organized and restrained. 

e Caution: ISS doesn’t allow long unbroken strings of 
Velcro due to flammability concerns. Maximum Velcro 
for a surface area is 2 inch (SOmm) squares separated 
by 2 inches (50mm) vertically or horizontally away from ag 
other Velcro, as in this picture of the Maintenance Work [ae = 
Area (MWA) mockup. a 


Nada ISS Human Factors Implementation Team (HFIT) 


e The ISS Human Factors Implementation 
Team (HFIT) is an optional service that 
provides hardware developers guidance in 
designing flight hardware crew interfaces 
that meet the Human Factors requirements 
and guidelines (SSP 50005 for ISS Systems, 
SSP 57000 for ISS Payloads). 


e The requirements are meant to prevent crew 
injury and avoid damage to neighboring 
hardware, and the guidelines are meant to 
facilitate mission success. 


e HFIT is available to U.S. Payloads, some ISS 
Systems, and International Partner (IP) 
Payloads in the U.S. Lab module 


e HFIT crew interface labeling review support 
is available to all ISS Payloads, upon request, 
and should occur no later than CDR 
timeframe. 16 


NASA ISS Human Factors Implementation Team (HFIT) 


¢ Nominal Human Factors Implementation Team (HFIT) process: 
e Assign HFIT rep at Payload Kickoff 
e Determine Applicable Human Factors Requirements (at/near System 
Requirements Review) 
e Perform Initial HFIT Evaluation (at or soon after PDR): 


e Assess prototype or mockup hardware for crew interfaces and labeling against applicable 
Human Factors requirements. 


e Identify issues early when it is more cost effective to influence design. 
e Provide recommendations on how the payload can comply with requirements. 
e Between evaluations: Support the Payload Developer as needed 
e Negotiate solutions to requirements-design conflicts. 
e Perform Final HFIT evaluation (after CDR or when flight hardware available). 
e Verify flight hardware meets requirements. 
e HFIT and Astronaut Office approve pre-coordinated, non-safety related non-compliances. 
e HFIT provides Certification of Compliance (CoC) after all issues closed. 


NASA ISS Human Factors Implementation Team (HFIT) 


e HFIT and Human 
Dependability 


e HFIT doesn’t study the 
fallibility of the human’s 
cognitive abilities itself. 


e HFIT’s design guidance 
recommendations help 
reduce design-induced 
errors for crew interfaces 
because designs are 
consistent with human 
expectations for how 
hardware should operate 
(intuitive). 


Nasa ISS Human Factors Implementation Team (HFIT) 


e In many cases, experiment real 
estate is limited and the PD 
must space hardware tightly. 


Having Human Factors involved 
helps the PD optimize spacing 
to allow for crew access. 


HFIT feedback helps 
choreograph the sequencing of 
mating tasks during installation 
Operations. 


Although the guidelines state 
you re not supposed to require 
removing one ORU or connector 
to gain access to another object, 
that cannot always be avoided, 
since the PD is trying to 
maximize their experiment’s 
capabilities in a limited volume. 


NASA ISS Human Factors Implementation Team (HFIT) 


¢ Common challenges of designing flight hardware: 


e Crew Accessibility 
e Tight spaces: As noted on the previous slide, maximizing science capability in a 
limited space can lead to crew accessibility issues. 
e Consider enlisting the help of someone unfamiliar with the design with large 
hands and arms, with the idea that their access would represent a worst case. 
e Reach issues: Sometimes the ability of the crew to reach an object is the biggest 
design driver. In that case, enlist the help of someone unfamiliar with the design 


with short arms to see if they can reach the object. 


e Strength 
e If strength, such as to torque a connector or crew actuated fastener, is an issue, 
enlist the help of someone with small hands, who may be weaker than then 
average person, to see if they can complete the task. 
e The goal is to design connectors and fasteners to be able to be tightened by 
hand, but if it’s not possible or there is any doubt about the crew being able to 
perform the task, then plan for a tool to be available. Standard ISS tools should 


be considered before designing unique tools. 
20 


NASA Examples of HFIT’s positive impact on design 


e Connector Spacing example 
Before HFIT After HFIT e Onthe image to the left, note the tight 
spacing of these electrical connectors. 

e The PD recessed the connectors hoping to 
meet the protrusion requirements in SSP 
57000. 

e However, the recessing in combination with 
the tight spacing made the mating of the 
connectors by hand impossible. 

e HFIT recommended the PD spread out the 
connectors as much as is feasible in the 
available real-estate. The CAD image to the 
right shows the PD’s updated drawing. 

e Labeling: Note that due to the connectors 
and associated controls arrangement, HFIT 
recommended labels be rotated 90 degrees 
to allow for the best group labeling and to 
avoid the risk of crew mis-associating one 
object’s label as being the label for a 
different object. 


NASA Examples of HFIT’s positive impact on design 


e No Handles for removal example 


e A double-locker payload’s PD was not planning to design handles for 
the crew to use for installation or removal. 


e The plan was for crew to push against flat area of the subrack to push it into 
the rack. 


e Pushing the subrack works for installation, but when the crew needs to 
remove the subrack, they would have had to pull on connectors or other 
objects not designed for such forces, and not placed in a symmetric layout 
that would provide even forces to pull the subrack out. Also, those 
connectors/other objects could be damaged in the process. 

e HFIT recommended the PD add handles on the front of the locker to provide 
even forces to aid the crew in removing the locker. 


e PD is now plans to implement low profile (flat) fabric handles that can 
be used to pull the subrack out easily. 


NASA Examples of HFIT’s positive impact on design 


e Lesson learned regarding why having 
handles is good design 


Consider the potential negative consequences of 
the crew using objects, such as cable and hoses as 
translation or stabilization aids. 


e Early in ISS, near the U.S. Lab window before the Window 
Observational Research Facility (WORF) rack was installed; 
multiple crew used a nearby U-shaped hose as a handhold Leaky Hose near U.S. Lab window, prior to WORF 
because it was the most convenient object to grab as a | 
restraint, and it looked like a handle! It lacked a 
Caution/Warning label telling crew not to grab it. 


e Over time, the hose (circled in red) was discovered to be 3 
the cause of a slow but steady leak of air from the ISS. The [= 
* 20 
hose was replaced. The risk could have been much worse 
than a slow leak. It could have caused a rapid depress of 
ISS. At a minimum, it wasted ISS resources. 


This isn’t the leaky 
hose, but a nearby 
cable that also 
happened to bea 
convenient handle 


Examples of HFIT’s positive impact on design 


e Lesson learned regarding why having handles 
Solution to Leaky Hose near U.S. Lab window . . . 
is good design (continued) 
= ‘ , TA, e A box was added to cover the hose. 


e Note the improvised handle made out of tape — not an 
ideal solution. 


e Two lessons: 

e Consider adding a handle to your hardware to prevent 
the crew from grabbing an object not designed to be 
used as a Stabilization or translation aid. The crew will 
use a handle when one is available. 

e If that is not possible, add a Caution label “CAUTION”, 
“Do not use object as a handhold. Damage may result”. 


e NBC Story on the leaky hose can be found at: 
http://www.nbcnews.com/id/4253674/ns/technology and 


science-space/t/space-station-crew-prepares-fix- 


Cover was added window/#.WcQfVmxe6UI 
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Examples of HFIT’s positive impact on design 


Similar to this kit e Kit falling apart example 


e During a final HFIT evaluation, a kit was found to be falling apart because the 
Velcro adhesive was not strong enough to keep the Velcro on the kit. 


e This could have led to contents floating away and getting lost, and increase 
crew time to find it or clean up any spillage. 


e The PD repaired the kit with better Velcro and reinforced with strong 


vere aaneel etalled adhesive. On-orbit problems were avoided. 


as in this example. 


Connector Clocking/interference example 


e Aconnector on the Control Unit of a payload was clocked in a way that 
interfered with a neighboring Ethernet cable because the spacing was tight. It 
was impossible to mate the needed connection at the HFIT evaluation, and 
this would have meant mission failure had it not been discovered. The 
clocking was modified, allowing the crew to mate the connection. 


e For this same payload, a few label mistakes were also found by HFIT. For 
example, some cable end labels with mating information didn’t match 
connector port labeling on the hardware. This could have led to the crew 
making mistakes, or wasted crew time to troubleshoot the discrepancy. The 
PD corrected the labeling. 25 


NASA Examples of HFIT’s positive impact on design 


e Labeling example 


e Labeling can have a big impact on the success of on- 
orbit operations. It is the crew’s first cue as to how 


to interact with hardware. ri oO 
e |t defines what objects are through their Operational a < 


Nomenclature (OpNom), and identifies all the items 
they will interface with. 


e When considering label designs, try to convey the 
meaning or function of objects in the most concise 
way to help the crew understand what they need to 
do. 


e Good procedures are a necessity, but clear labeling 
can prevent the crew having to call down to Mission 
Control to ask how to perform a task if the labeling 
stands is clear. 


e Astronauts like to understand the meaning behind ~ 
the science of payloads, because it helps them PHase ANG y 
describe such research during public affairs oC — > 
interviews, but labeling should not be so complex as BG ™~ 
to be confusing. 


fits 


e Labeling example, continued 


In the example to the right, 
there were many similar, 
intricate capillary hose and 
test stand connections for 
crew to mate. 


HFIT recommended using 
simple color coding and 
numbering that will stand 
out to help crew make the 
right connections. 


Note: Normally red and 
yellow are reserved for 
Caution and Warning 
purposes, but from the 
context here it is obvious the 
colors only denote 
connectivity relationships. 


Nasa > Clanlimelmelalceladelar-lx-Mel-it-4a mene) (at 


e LED color selection example 


e There is a payload that used a red LED to indicate that it is 
operating properly. The ISS crew thought enough about this 
example to call it out specifically in an ISS crew debrief as being a 
problem for them on-orbit. 

e For ISS Systems and payloads, Green is meant to convey 
hardware/software operating properly (nominally) with no faults. 

e Red and yellow are reserved for ISS System-level Cautions and 
Warnings. 

e Since payloads are not supposed to negatively impact ISS Systems, 
orange is reserved for “payload alerts”, when a payload is not 
functioning properly. 


e Excessive white space on labels example 


Payload cable labels were huge and 
contained more white space than needed to | Peer 
hold the text, maximizing the footprint of a =) | Example of too 
the labels. much white space 
This was considered a big deal by upper ISS on cable labels 
management who saw the cables. 
Management made the PD fix the labels, 
although it technically didn’t meet the RISE 
criteria of preventing crew injury or 
neighboring hardware damage. 


Overly large labels can make cables more 
unwieldy to interact with and exacerbate 
visual clutter. 


The goal is to have large enough text for 
labels to be readable, but minimize the 
footprint of the label itself. See good 
examples to the right. 


Example of readable 
cable labels with 
minimum white space 


Nasa HFIT’s role in Cost Avoidance 


e In 2002 and before, there were a large number of Human Factors 
requirements violations 


A large majority (2/3rds) of the Exceptions (waiver requests) for SSP 
57000 requirements were due to Human Factors requirements non- 
compliances. 


ISS determined that each Exception cost the program an average of 
$15,000 to process, including the time it takes for various stakeholders 
and program personnel to review the Exception and support meetings. 


e For the first 4 years of HFIT (2003-2007): 


160 Exceptions were avoided, because either: HFIT and the PD were 
able to avoid non-compliances altogether, or HFIT accepted the non- 
compliances because they were minor, and not safety-related. 


Based on the average cost of processing an Exception, an estimated $2.4 
million was saved by avoiding Exception reviews and meetings. 
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Nasa HFIT’s role in Cost Avoidance 


e ISS Program processes have changed since the early HFIT years, 
but it reasonable to assume the $2.4 million savings has at least 
tripled. 


e Perhaps not quadrupled, because there are generally fewer requirement non- 
compliances compared to the early HFIT years, because PDs have learned how to 
comply with the requirements. 


© Cost savings to the program in terms on reduced crew time to 
operate or troubleshoot payloads is hard to quantify, because 
problems were avoided. 

e The key to saving money for the life-cycle of flight hardware is to 
have Human Factors involved early and often. 
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NX ° 
Nasa Human Factors Requirements News 


e Human Factors requirements in SSP 57000, section 3.12 


e Before RISE: There were 103 “shall” requirements (formally 
verified), 4 “should” guidelines (SSP 57000 Rev P) 


e After RISE: There are 26 “shall” requirements, 46 “should” 
guidelines (SSP 57000 Rev R) 
e To remain a “shall”, the requirement must prevent crew injury or prevent 
damage to neighboring hardware. If violating the requirement only hurts 


the payload in question, or relates to the mission success of the payload, it 
was reduced to a guideline. 


e Crew Interface Label Requirement and the Appendix of instructions it 
points to were kept largely intact, with few updates. 
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4 Human Factors Labeling Requirements News 


e ISS Label Requirement and Process Improvement TABLE 3.12.7.2.1-1 BASIC LABELING REQUIREMENTS 
Team, formed in late 2016 to All items All items on hardware that have a crew interface are to be 
e Im prove Payload la bel req uirements in SSP 57000 labeled identified, including, but not limited to: controls, switches, 
‘ : ee connectors, LEDs, containers, vents, valves, etc. 
to better meet RISE criteria (prevent injury or 
neigh bori ng hardware da mage), and reduce Rationale: Identifying every crew interface item is important 
lication 
du P eane Label per Labels for crew interfaces are to contain information 
e Im prove the eLabel process operational regarding the operational purpose, or function. For example, 
e Issues with the tool (e g software bugs non- purpose controls need to be labeled in terms of their function (e.g. 
: as bos ! power, data). 
intuitive features) have frustrated ISS payload 
develo pers Wa nti ng to receive label a pprova . Rationale: Labeling hardware items per their operational 
purpose ensures the crew safely operates the hardware as the 
PD intended and avoids hardware damage that human error 
e Major Payload Label Requirements Update could cause. 
A dix O deleted ‘ t d ideli : All flight hardware with crew interfaces are to be identified 
. Ppenaix e€ eted, requirements and guidelines with the ODFCB approved OpNom, SSP 50254 and 
moved to section 3.12 applicable partner annexes. This includes the list of contents 
e Reduced label requirements to 10 high level en slo war crcontamer 1Apels, aud apronyins:and 
“shall” requirements with associated tables of eleen 
detailed how-to requirements. Guidelines Rationale: This is critical to rapidly and accurately 
similarly have tables of instructions. identifying hardware items. 


Part and Serial | Flight hardware is to be labeled with its part number 


_ , : ‘ 
° 40% reduction in requirements Numbers (required) and serial number (if exists). 


e No duplication 
e Requirements are clearer, organized better 


Rationale: This is critical to rapidly and accurately 
ing hardware items. 
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NASA HFIT Points of Contact 


Flight Crew Integration (FCI) 
= Laura Duvall: 1.281.483.0244 (NASA FCI System Manager) 
= Rich Ellenberger: 1.281.483.5238 (NASA FCI System Manager Deputy) 


Payload HFIT Representatives 

=» Juan Davaloz: HFIT Contractor Lead 

= Jenae Aber: HFIT team member 

# Antonius Widjokongko: HFIT team member 
= Nicole Schoenstein: HFIT team member 

= Sean Schimelpfenig: HFIT team member 

=» Pam Fournier-Gonzalez HFIT team member 


